Asynchronous networks, such as Ethernet networks, increasingly are being used to transmit real-time, synchronous, and/or time-sensitive data. To illustrate, wireless carriers often implement fiber-optic based Ethernet (“Optical Ethernet”) networks to transmit voice data to/from a central office (CO) or point-of-presence (POP) to base transceiver stations. Likewise, various circuit emulation protocols for packet-based networks, such as Voice over Internet Protocol (VoIP), are commonly used to transmit real-time voice data over packet-switched networks.
These asynchronous networks often offer a number of advantages over synchronous networks, such as improved flexibility, increased bandwidth, widespread usage, less expense to implement, and the like. However, asynchronous networks often are at a disadvantage when used to transmit synchronous or real-time data. For one, unlike synchronous networks, asynchronous networks typically have jitter and wander that is unbound, making it difficult for the proper utilization of synchronous data at the receiving network device due to the indeterminate timing of the data. Additionally, most asynchronous networks do not have an inherent scheme to transmit clock synchronization information throughout the network, further compounding timing issues at receiving network devices.
FIG. 1 illustrates the difficulties of transmission of real-time/time-sensitive data over asynchronous networks in conventional systems. Depicted in FIG. 1 is a conventional VoIP system 100 having a synchronous network segment 160 and an asynchronous network portion 170. The synchronous network segment 160 includes a clock source 102 and a network device 106 connected via synchronous data link 172. The asynchronous network segment 170 includes network devices 108 and 110 connected to the network device 106 via asynchronous data links 174, 178, respectively. The illustrated conventional system 100 further includes a network device 112 connected to the network device 108 via asynchronous data link 176 and supporting a Voice Over Internet Protocol (VoIP) application 150.
The source 104 is adapted to provide real-time VoIP data to the VoIP application of the destination network device 112 via network devices 106, 108, whereby a user's voice at the source 104 is converted to digital data and packetized into packets 142, 144 along with the appropriate timestamps. The packets 142, 144 then are transmitted as part of a synchronous data stream over the synchronous network segment 160 to the intermediary network device 106. The network device 106 prepares the packets for transmission over the asynchronous network segment 170 and provides the packets 142, 144 as part of an asynchronous data stream to the intermediary network device 108, which then forwards the packets 142, 144 to the destination network device 112. At the appropriate time, as determined by the associated timestamp and the local clock of the network device 112, the VoIP application 150 extracts a data payload from the jitter buffer converts the data payload to an audio output for the user of the destination network device 112.
VoIP applications often are used to transmit voice conversations over packet-switched networks, such as the Internet. At the source of the voice conversation, the analog voice signal is sampled at a frequency of, for example, 8 kilohertz (kHz), resulting in a sample every 125 milliseconds (ms). After each sample is obtained, the source network device packetizes the sample along with a timestamp and transmits the packet over the packet-based network to the receiving network device as part of a stream of packets from the source network device. Ideally, the receiving network device then would extract a sample from the stream of packets and, using the associated timestamp, provide the appropriate sample for audio output every 125 ms. It will be appreciated, however, that actual asynchronous networks often experience considerable variation in both wander and jitter. Packets are often received out of order, dropped, and so on, resulting in an output sound quality that is less than optimal. Since such asynchronous networks typically do inherently implement a clock synchronization signal, the output sound quality is further degraded due to the variation in the operation of the clock at the source network device and the clock at the receiving network device. Such variation can cause the receiving network device to output the sample sooner and/or later than intended, resulting in clipped or garbled audio output.
Accordingly, it often is desirable to maintain synchronization between the clock (CLKREF) of the source 104 and the local clock of the destination network device 112 to prevent overflow/underflow of the jitter buffer, improper timing in the playout of data by the VoIP application 150, and the like. It will be appreciated, however, that the packets 142, 144 have timestamps synchronized to the reference clock 102, whereas in the conventional system 100, the VoIP application 150 may be synchronized to the link 176. However, the link 176, being an asynchronous data link (e.g., Ethernet), typically does not provide for synchronization with the clock reference signal. To illustrate, link 174 between network device 106 may carry a clock signal CLK1, the link 176 between the network device 108 and network device 112 may carry a clock signal CLK2, and the link 178 between network devices 106 and 110 may carry a clock signal CLK3, where each of clock signals CLK1, CLK2, and CLK3 may vary significantly from CLKREF. For example, in Ethernet, the variance often can be approximately 100 parts per million (ppm), resulting in a potential variance of 300 ppm for CLK3. Accordingly, the VoIP application 150, when using CLK3, as its reference may experience a number of errors when receiving and decoding the VoIP packets from the source 104, such as dropped packets, buffer overflow/underflow, and the like.
In response to the need for asynchronous networks to support clock distribution for legacy systems, such as private branch exchanges (PBX), wireless base stations, Internet servers, video terminals, T1 multiplexers, voice and video applications, and the like, a number of techniques have been developed to provide clock synchronization throughout an asynchronous network. One technique commonly implemented in packet-switched networks includes the synchronization of the transmitter clock and the receiver clock using timestamps. The transmitting network device sends a series of explicit time references as timestamps in a sequence of packets and the timestamps are used by the receiving network device to synchronize its clock to that of the transmitting network device. Since no common network clock is used, the receiving network device relies on locking its clock to the arrival of the timestamps using one or more complex clock synchronization algorithms. However, due to the transmission time dispersion prevalent in packet-based networks, these clock-recovery algorithms often are inaccurate, thereby affecting the processing of the synchronous data at the receiving network device. These timestamp-based synchronization techniques are exemplified by the Network Time Protocol (NTP) and IP Layer 3 Plus timestamping.
Another common method for clock synchronization support in asynchronous networks includes using Global Positioning System (GPS) to obtain a common clock signal. In such implementations, some or all of the network devices of the asynchronous network includes a GPS receiver adapted to receive radio signals from GPS satellites and to extract a timing reference from the signal. Each of the network devices utilizing the GPS signal in theory are then synchronized to the GPS timing reference. However, GPS-based clock synchronization techniques have a number of limitations. For one, the GPS-based clock synchronization systems often are cost-prohibitive due to the expense of the GPS receivers. Also, problems may arise when the network device is located within a building or otherwise does not have a line-of-sight with a GPS satellite, making it difficult if not impossible for the GPS receiver of the network device to receive a GPS signal from which the timing reference is to be extracted.
Alternatively, techniques have been developed to transmit synchronous data over an asynchronous network. One such technique is detailed in, for example, U.S. Pat. No. 6,246,702, entitled “Methods and apparatus for providing quality-of-service guarantees in computer networks,” issued Jun. 12, 2001. This technique typically includes configuring the network adapters of a network device to control the timing of the transmission and reception of packets by distributing a clock reference embodied as a frame, where each network adapted is assigned a different portion of the frame in which it can transmit and/or receive. This technique requires specialized packet traffic engineering and, by doing so, increases the complexity of the management procedures. Additionally, by assigning each adapter to a specific portion of the frame, the benefits of asynchronous transmission/reception are lost.
In view of the foregoing, it would be desirable to provide a clock synchronization technique that overcomes the above-describe inadequacies and shortcomings. More particularly, it would be desirable to provide a technique for clock synchronization in an asynchronous network and/or hybrid network in an efficient and cost-effective manner.